Routing of messages from a source node to a destination node in networks, such as for example packet switched networks (PSN's), is performed automatically by the use of routing tables. A routing table is located at each node of the network and contains information as to the link set between nodes that the message is to be transmitted. This information usually includes a preferred or normal route and one or more secondary or failure routes.
Signaling System No. 7 (SS7) interconnects stored program control exchanges, network data bases and intelligent peripherals of telecommunications management networks. SS7 is used to exchange messages and information respectively related to call management and to distributed applications and network management. The protocols of SS7 have been standardized by the "Comite Consultatif International pour le Telephone et le Telegraphe" (CCITT) which is known today as the International Telecommunications Union (ITU)--Telecommunications Standardization Sector (TSS).
To operate properly, the correct routing table information is loaded and stored in each table at system start-up or generation. This information is constant and the routing table is described as "static". The routing tables may also be described as "partial path" because the information stored in each table relates only to the next node on the way to the destination. The integrity of the routing information stored in the tables is fundamental to the normal functioning of the network.
Network communication problems arise when the routing information in tables is incorrect or becomes corrupted. One example of a problem is when the table fails to contain an entry for a destination node causing the message to stop at that node and to fail to make it to its destination. Another problem example occurs when two or more node tables contain destination information directed to each other resulting in the message traveling in an endless loop. A third message transmission problem occurs when the message tree between the source node and the destination node results in an excessive length route where the message crosses more STP's than the maximum allowed STP's in the network. Still yet another problem occurs when the signal path through the network is unidirectional. That is to say the message can travel in one direction through the tree from the source node to the destination node but it cannot travel in the reverse direction from the destination node to the source node.
In SS7 networks there are currently two methods used to check the correctness of SS7 routing tables.
The first method involves checking "off-line" the correctness of the routing data before the introduction of this data to the tables. Various simulation methods are used for to check the information. The problem with this method resides in errors introduced during the manual data entry of the information in the table for each node by the operational staff. Further, data corruption can occur after entry. This "off-line" method of testing table data information does not safe-guard against errors occurring during loading of the data in the tables or against errors due to data corruption.
The second method used to check the correctness of SS7 routing tables is a real time check of the table routing data in the network. It consists of auditing "on-line" during network operation the routing data after it has been introduced in the tables. There are two known "on-line" tests in use today to check the correctness of SS7 routing data. These tests are known as the Message Transfer Part (MTP) Routing Verification Test (MRVT) and the Signaling Connection Control Part (SCCP) Routing Verification Test (SRVT). The MRVT and the SRVT check respectively the content of the Message Transfer Part (MTP) routing tables and the content of the SCCP routing tables. These tests are initiated at one or more predetermined source nodes to test the routes messages will follow to respective predetermined destination nodes. Usually each test results in the message following all possible routes to its test destination. This is done by sending multiple test messages and tracking the identities of all nodes crossed by the message. Information on the success of this testing is transmitted back to the destination node. An example of an "on-line" testing procedure is disclosed in U.S. Pat. No. 4,745,593 issued May 17, 1988 to Gilbert M. Stewart.
One problem associated with this routing verification testing is the extra network loading associated with the testing. The networks are already operating under time restraints to deliver messages between source nodes and destination nodes. The introduction of the "on line" testing to be thorough should be conducted periodically in the SS7 network as suggested by the ITU-TSS standards. During each period, from every node, a test is run against all the destinations which can be reached from the node. For example, if a network has 20 nodes, there could be hundreds of possible test routes to follow in one test. This one test could significantly load the network. SS7 networks are signaling networks with very stringent delay objectives that the networks can hardly meet when they are overloaded. Consequently, operators are reluctant to perform tests of routing tables in networks.
In view of the foregoing, it can be appreciated that there is a problem with routing table information and the verification of that information particularly after the table information has been loaded into the network. There does not appear to be a solution available to the operator to check periodically "live" information without the risk of unduly overloading the network with test messages and placing legitimate messages at risk of being lost. This risk is more serious when many tests are started at the same time or very close in time such that several tests are running at the same time.